Many organisations throughout industry and commerce, such as banking, insurance, finance, healthcare etc, have a common requirement to receive and process complex data relating to individual customers that they serve. For example, insurance organisations need to capture large quantities of personal information from individuals, which information include names, addresses, ages, personal circumstances, lifestyle details, health details, insurance cover requirements, and so on. Conventionally, the most convenient way to do this has been by the use of forms, which can be presented in hard copy, or preferably presented on a computer monitor, enabling direct capture of the entered data onto computer storage media.
Many of the data values entered by a user actually determine the type and range of further questions that must be asked of the individual, and thus it is desirable that the computer system verify the accuracy of the data, in real time, during data entry, and then use a rule-based system to determine further forms for presentation to the user based on the prior data entry.
While this type of form-based data entry and capture is a very convenient and accurate method for the user, the initial set up costs for providing suitable, well-presented forms with underlying data capture logic that exactly match each organisation's specific data capture requirements is a complex task that requires advanced programming skills.
Each form must be specifically customised in terms of the presentation and content of questions or prompts to be displayed to the user, the format of data to be received, the validation rules for checking the data as it is being entered, and rule-based actions executed in real-time which determine outcomes based on the data values received, such as determining further data capture requirements based on the received data.
The data capture logic must not only determine the information content and layout of the forms presented to the user, the data validation functions and the rules for use during form execution, but also must define how the data should then be exported to (eg. mapped into) the organisation's database, or exchanged with other databases. Clearly, the persons who are best placed to comprehend and define the organisation's data capture requirements (ie. the “business experts” who have detailed knowledge of the business requirements behind the data) are not likely to have the advanced programming skills necessary to implement the electronic data capture functions.
There are a wide variety of prior art computer applications which enable a person (acting as a form architect) to define an electronic data capture or exchange.
Many of these prior art systems provide WYSIWYG-type form building or data exchange capabilities intended for backoffice, client/server or traditional desktop environments, and may include facilities to define the function—ie. the data validation and rule based actions.
Some prior art applications allow a data model to be defined, enabling the data capture to be contained, transported and exchanged according to a predetermined standard.
Some prior art applications provide a means of central control where multiple users have assigned roles to manage the application usage.
Additionally, there are tools and utilities available, which can be used to define an electronic data capture or exchange, but these do not provide interfaces to abstract the form architecture from the underlying technology or expertise required in order to utilise the data capture or exchange.
Thus, there are a significant number of problems with the prior art approaches.
i) The WYSIWYG-based applications are prescriptive in their approach to form design. As shown in FIG. 7, an architect 8 defines data capture by use of a visual form 1 with positional (x-y) co-ordinates, upon which the architect graphically places the data items to be captured, ie. textboxes, radio buttons, drop down lists, menus etc.
The problem with this approach is that the architect is graphically designing a form 1, according to a specific target of execution 22 (ie. a single data capture requirement, rather than an approach of intent where the architect 8 merely specifies what data is to be captured or exchanged (ie. the intent).
ii) In the prior art, the target execution of a data capture and/or exchange built using a WYSIWYG-based application is restricted to the specific technology or platform 22 in which the application operates. As illustrated in FIGS. 5 and 6, if a data capture/exchange is required for execution across multiple technologies/platforms, in the prior art, the architect is required to repeatedly define the form 1, function 2 and data model 3 container, using a different application for each single specific execution purpose 22 technology platform required. As shown in FIG. 5, each implementation of a form requires a separate build process for each different technology/platform, even though there might only be one set of data capture requirements, rules/function and data model.
In this regard, XML tools and utilities can be used to create a single XML document to achieve this purpose, but this requires that the architect possesses the necessary XML technical skills and understanding of the XML dialect and schema employed. The architect 8 is not provided with an environment with which they can specify their requirements of the data capture and/or exchange.
iii) Using WYSIWYG-based applications, a defined data capture executed as a form cannot also be used as part of an automated data exchange mechanism between systems. Some of these applications can be used to create data exchange mechanisms, or components thereof, but this is a separate function, and an existing defined data capture plays no part in the construction or use of the data exchange, requiring the data definition 21, function 2 and data model 3 to be redefined.
In this regard, XML tools and utilities can be used to create a single XML document to achieve this purpose, but this requires the architect to possess the necessary XML technical skills and understanding of the XML dialect and schema employed. The architect 8 is not provided with an environment with which they can specify the requirements of the data capture and/or exchange.
iv) None of the prior art described above provide the ability for the architect to construct a form according to an XML form definition standard, and validate that form against it, without requiring the appropriate XML technical skills and knowledge of the XML dialect employed.v) None of the prior art described above provide the ability to automate form construction based on an XML form definition standard, or parts thereof. The architect has to manually construct the form. Some applications will automatically generate a form based on a database table definition or similar, but this does not constitute a form definition standard, and the automation uses the entire table or model, rather than selected part(s).vi) None of the prior art described above, provide the ability for the architect to define the data model container for the form or to set conditions against which the form data is bound to the data model, without requiring appropriate XML technical skills and knowledge of the XML schema employed.vii) None of the prior art described above supports the specific combination of creation, use, re-use and propagation of entire or part forms as templates, by multiple users with assigned roles and rights, utilising locking at form level to prevent conflicts.